Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.31%. Comparing base (d4389e5) to head (f5f79bd).

@@            Coverage Diff             @@
##             main     #551      +/-   ##
==========================================
+ Coverage   85.26%   85.31%   +0.05%     
==========================================
  Files          28       28              
  Lines        3433     3433              
  Branches      601      601              
==========================================
+ Hits         2927     2929       +2     
+ Misses        313      312       -1     
+ Partials      193      192       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

CodSpeed Performance Report

Merging #551 will not alter performance

_{Comparing return-tuples-not-lists (f5f79bd) with main (d4389e5)}

Summary

✅ 6 untouched

Interesting, it breaks Cython. Was not expecting that. It may be a breaking change after all.

Well, not breaking in the semver sense since we aren't changing the library itself. But rather would be a feature to allow Cython to accept tuple in addition to list.

I'll have to think about this some more.

There are two sides to this, only one of which has been addressed so far.

The first is relaxing the allowable types for body as an input. This is what has been done here so far. Other than the one type change for Cython that is needed to make it work at runtime, it is just a matter of type hints. I've made everything list[Any] | tuple[Any, ...], but that is rather verbose and we could actually replace it with Sequence[Any] (from collections.abc).

The part I haven't addressed though is that I've just realized that in addition to #526 there is also the case where returning multiple values should also be implemented as a tuple to allow for correct type hints. However, it is currently implemented as a list. Where this matters is for proxy types. We likely need it to be a list when unmarshalling messages to avoid issues with tuple immutability, i.e. a performance cost for having to create a new tuple object every time we unmarshal the next element.